From owner-onions  Fri Jan 29 10:40:25 1999
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA04494
	for onions-outgoing; Fri, 29 Jan 1999 10:39:51 -0500 (EST)
Received: from itd.nrl.navy.mil (fw1-5540.itd.nrl.navy.mil [132.250.80.6])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA04482;
	Fri, 29 Jan 1999 10:39:47 -0500 (EST)
Received: from banana-jr.fw5540.net (banana-jr.fw5540.net [10.0.2.1])
	by itd.nrl.navy.mil (8.9.0/8.9.0) with SMTP id KAA09816;
	Fri, 29 Jan 1999 10:38:51 -0500 (EST)
Date: Fri, 29 Jan 1999 10:38:50 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
cc: Onion-Info <onion-info@itd.nrl.navy.mil>
Subject: Move to more powerful machine...
Message-ID: <Pine.GSO.3.95.990129102946.22079D-100000@banana-jr.fw5540.net>
X-Personal: False
X-Anonymous: False
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Onioneers-
	We have moved the NRL testbed Onion Routing Network to a new,
more powerful machine.  The DNS entries have been maintained, but they
point to the new physical/logical location (we also moved to a
dedicated 100Mbit drop directly off our backbone) -- the new IP
address is 132.250.196.3.  The new machine is a Sun Ultra 450 with
512MB of memory, 10GB of swap, and four 300Mhz processors running
Solaris 2.6 and our first generation prototype code.  We're still
processing over a million connections per month, and with the new CACM
article out on the streets, we expect more load in the near future
(see the February issue of CACM which is all about privacy and
anonymity on the Internet).  We now have two watchdog processes
running on the machine to help keep the system up 24x7 (they watch the
'health' of the system and if components fail, restart the necessary
portion of the network).
	The TNG code development is wrapping up (we are currently
undergoing the NRL publication review process and will hopefully be
able to make the code available to the public in a month or two) and
we will begin limited testing shortly.  Please contact us at
onion-info@itd.nrl.navy.mil if you want early access to the TNG code
for review or testing purposes.

-Michael
 Chief Onioneer


From owner-onions  Mon Apr 19 15:27:24 1999
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA06753
	for onions-outgoing; Mon, 19 Apr 1999 15:26:01 -0400 (EDT)
Received: from itd.nrl.navy.mil (fw1-5540.itd.nrl.navy.mil [132.250.80.6])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA06748
	for <onions@smtp.itd.nrl.navy.mil>; Mon, 19 Apr 1999 15:25:59 -0400 (EDT)
Received: from banana-jr.fw5540.net (banana-jr.fw5540.net [10.0.2.1])
	by itd.nrl.navy.mil (8.9.0/8.9.0) with ESMTP id PAA09877
	for <onions@itd.nrl.navy.mil>; Mon, 19 Apr 1999 15:25:04 -0400 (EDT)
Date: Mon, 19 Apr 1999 15:25:03 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Back up on-line
Message-ID: <Pine.GSO.4.10.9904191455460.8121-100000@banana-jr.fw5540.net>
X-Personal: False
X-Anonymous: False
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

All-
	For those users of the NRL testbed onion routing network,
we're back on-line after experiencing a slight political difficulty
(not to be confused with a slight technical difficulty :-).  The issue
has been resolved (read: we convinced them that they were wrong :-)
and we resumed processing at 1319hrs EDT today (we went off-line
around 2000hrs EDT this past Friday).  Sorry for the inconvenience.

-Michael
 Onioneer


From owner-onions  Wed Apr 21 10:29:44 1999
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA19793
	for onions-outgoing; Wed, 21 Apr 1999 10:28:17 -0400 (EDT)
Received: from nrnsinc.on.ca (ns.nrnsinc.on.ca [209.47.4.66])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA19787
	for <onions@itd.nrl.navy.mil>; Wed, 21 Apr 1999 10:28:14 -0400 (EDT)
Message-ID: <371DE0F5.1A8556C0@nrnsinc.on.ca>
Date: Wed, 21 Apr 1999 10:30:13 -0400
From: Joe Spagnolo <Joe.Spagnolo@nrnsinc.on.ca>
Reply-To: Joe.Spagnolo@nrnsinc.on.ca
Organization: NRNS Incorporated
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: onions@itd.nrl.navy.mil
CC: Joe Spagnolo <Joe.Spagnolo@nrnsinc.on.ca>
Subject: A couple of questions on TNG OR prototype
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Hello,

We had a look at the first OR prototype. The list of planned enhancements
for TNG OR prototype is very impressive. I do have a few questions 
however.

The first prototype does not perform link padding. In the "Onion Routing 
for Anonymous and Private Internet Connections" (Communications of 
the ACM, vol. 42, num. 2, February 1999) article, it states that
"long-standing connections between onion-routers can be padded and
bandwidth limited to foil external observers". Is this capability
included in or planned for TNG OR prototype?

Although TNG OR prototype includes support for reply onions, the
ACM article only states that they "could be used to send anonymous
replies in response to a previously received anonymous email". 
Will TNG SMTP proxy support this? If so, is the intent to have
reply onion built by the initiator's local SMTP proxy?

Can access control policies be used to select the exit Onion Router
for locally initiated connections? For example, can I insure that
the NRL onion router will be the exit onion router when my site 
communicates with NRL? I assume this is necessary to properly support
VLANs. Can I control how many intermediate ORs are used? 

Thanks in advance.

--
Joe Spagnolo
NRNS Incorporated
613-599-7860 ext 103

From owner-onions  Wed Apr 21 11:11:03 1999
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA21275
	for onions-outgoing; Wed, 21 Apr 1999 11:10:48 -0400 (EDT)
Received: from itd.nrl.navy.mil (fw1-5540.itd.nrl.navy.mil [132.250.80.6])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA21264;
	Wed, 21 Apr 1999 11:10:43 -0400 (EDT)
Received: from banana-jr.fw5540.net (banana-jr.fw5540.net [10.0.2.1])
	by itd.nrl.navy.mil (8.9.0/8.9.0) with ESMTP id LAA04333;
	Wed, 21 Apr 1999 11:09:45 -0400 (EDT)
Date: Wed, 21 Apr 1999 11:09:39 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Joe Spagnolo <Joe.Spagnolo@nrnsinc.on.ca>
cc: onions@itd.nrl.navy.mil
Subject: Re: A couple of questions on TNG OR prototype
In-Reply-To: <371DE0F5.1A8556C0@nrnsinc.on.ca>
Message-ID: <Pine.GSO.4.10.9904211102120.10431-100000@banana-jr.fw5540.net>
X-Personal: False
X-Anonymous: False
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 21 Apr 1999, Joe Spagnolo wrote:
|>We had a look at the first OR prototype. The list of planned enhancements
|>for TNG OR prototype is very impressive. I do have a few questions 
|>however.

Thanks!  You feedback before was very valuable, and we look forward to
it this time around as well :-)

|>The first prototype does not perform link padding. In the "Onion Routing 
|>for Anonymous and Private Internet Connections" (Communications of 
|>the ACM, vol. 42, num. 2, February 1999) article, it states that
|>"long-standing connections between onion-routers can be padded and
|>bandwidth limited to foil external observers". Is this capability
|>included in or planned for TNG OR prototype?

Yes, both are included.

|>Although TNG OR prototype includes support for reply onions, the
|>ACM article only states that they "could be used to send anonymous
|>replies in response to a previously received anonymous email". 
|>Will TNG SMTP proxy support this? If so, is the intent to have
|>reply onion built by the initiator's local SMTP proxy?

We are still working out how to deal with this.  There are a number of
possible ways to deal with it that depend on whether or not replay is
allowed of the reply onion.  The initial code release of ORtNG will
probably not include reply onion support in the proxies, but will
follow shortly afterwards.  Reply onion support is slated to show up
in SMTP & HTTP initially, and we'll be looking at some of the other
protocols later.

|>Can access control policies be used to select the exit Onion Router
|>for locally initiated connections? For example, can I insure that
|>the NRL onion router will be the exit onion router when my site 
|>communicates with NRL? I assume this is necessary to properly support
|>VLANs. Can I control how many intermediate ORs are used? 

Yes to all the questions.  There are some possible ramifications to
doing this automatically, so you may not want to make use of positive
rights in the ACLs (people can publish them, but you may want to
ignore them).  For example: Attacker.com may want to sniff traffic
destined for Innocent.com.  Attacker.com could announce a positive
exit policy for Innocent.com even though he has nothing to do with
Innocent.com (he just wants to sniff) thereby steering traffic out his
onion-router which he can then sniff before sending the data on to
Innocent.com.  We've built in external audit capabilities so this
attack can be detected, and as always, a initiating proxy may choose
to ignore the positive rights published by Attacker.com and therefore
not be steered that way.  There are some other subtle things at work
here as well...

- -Michael
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